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ABSTRACT 


This MBA project investigates the importance of correctly deriving requirements 
from the capability gap and operational environment, and translating them into the 
processes of contracting, software and hardware design, system engineering, the 
acquisition cycle, and program management. 

The research also examines inefficiencies in hardware and software development, 
acquisition management, and problems caused by organizational, systemic and 
stakeholder interferences. The primary goal is achieving the acquisition process to deliver 
the best quality system that is prompt, technically available, affordable, and meets the 
user’s requirements. 

The work addresses commonalities and differences of software and hardware 
development, inefficiencies, and a variety of influential factors for a new program from a 
more general perspective. The conclusions and recommendations illustrate the present 
difficulties of implementing constructive change. These recommendations are provide the 
reader with alternative approaches to consider. 

Suggestions for further research are included at the end of this research. 
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I. HARMONIZED CONSTRAINTS IN SOFTWARE 
ENGINEERING AND ACQUISITION PROCESS MANAGEMENT: 
REQUIREMENTS ARE THE KEY TO SUCCESSFULLY MEET 
FUTURE PERFORMANCE GOALS IN AN ENVIRONMENT OF 

SCARCE RESOURCES 


A. INTRODUCTION 

The acquisition community, Congress, companies, and taxpayers consider the 
Department of Defense (DoD) acquisition process to be a broken system. They are weary 
of endless program failures, cost overruns and delayed schedules for major acquisition 
programs. However, this is the only commonality of their judgements. Stakeholders do 
not enjoy being reminded of their own contribution to the mess and are more than willing 
to pass the blame to anyone else. They all have different opinions of what is wrong with 
the sophisticated system, which appears to be sensible when considering the process 
alone. Budgets will remain tight in the future because there are many other challenges, 
apart from the defense budget, appearing at the horizon. Everyone agrees that the system 
needs to be fixed quickly because of the scarce resources apparent in future budgets. 
Gathering a sufficient piece of the budget is essential to providing high quality weapons 
systems to the warfighters that are desperately needed to face upcoming threats and 
challenges. 

Modernization and unexpected developments must be addressed as well. 
Considering the tight budget constraints, this is a difficult task. The need for a solid, fast 
and reliable solution to this inappropriate situation is urgent, and requires extensive 
analysis. The goal is to find the roots of the various problems in order to make the system 
work. Two of the most critical causes of acquisition problems are the development of 
sufficient system and software requirements. To understand this relationship, the facets of 
this complex and complicated system must be examined: important stakeholders, 
influential factors, and the challenges and opportunities ahead. Goals of the Project are 
illustrating common problem areas, developing new insights, addressing future needs, 
and offering recommendations for addressing some of the current weaknesses. 
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B. COMMONALITIES AND DIFFERENCES 


To understand the role of software development and general requirements within 
the acquisition process, the commonalities and differences of these two segments will be 
examined. 

1. Commonalities 

Software and general requirements are derived from the same source: the goal 1 of 
closing a capability gap. The functional analysis, which is driven by the operational 
requirements needed to achieve this goal, leads to both preliminary and detailed design 
attributes. 

2. Differences 

The functional analysis step is where the two kinds of requirements deviate. 
General requirements investigate the design attributes needed for the physical 
characteristics of the new system. Software requirements identify the attributes and 
important functions that will be performed by software in the new system, not by 
hardware of the preliminary design 2 . Both address the interfaces, testing, and 
integration 3 necessary for the new system to work smoothly and reliably using different 
means. All these efforts take place during the design phases before the actual production 
process. What is evident from this is that the requirements must be generated in a 
completely different environment within the acquisition process. The further 
development of these requirements, beginning with the functional analysis, is completely 
different and often misunderstood. 


1 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 99, Figure 4.3. 

2 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 100, Figure 4.4. 

3 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 100, Figure 4.4. 
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c. 


METHODOLOGIES AND MODELS 


This research uses various analytical techniques referring to case studies and 
models to illustrate the roots of problems within the acquisition process. It also uses 
models, data and case studies to support the recommendations and conclusions. 

D. SHORTFALLS IN THE INFLUENTIAL FACTORS AND THEIR IMPACT 
ON THE SUCCESS OF A MAJOR ACQUISITION PROGRAM 


First, it is necessary to present the most common and important sources that lead 
to the frequently experienced shortcomings of cost and schedule overruns. The research 
investigates their general impact on major acquisition programs and focuses on six major 
sources for each segment. These sources are not exhaustive but address the most 
influential areas of the current weaknesses experienced within the different processes. 

1. Shortfalls in the Software Segment and Their Impact 


Figure 1. Major shortfall areas in software development 



a. Lack of Understanding Software Requirements 

At the beginning of the acquisition process, detailed software requirements 
of the new system are always unknown because the overall amount of software required 
is determined by the functional needs that are elaborated early in the acquisition process. 
It is essential that the user requirements be correctly translated into software requirements 
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that address the system attributes derived from the functional architecture. It is 
particularly important to accurately estimate the amount of software development needed 
with as much realism as possible. 

Another crucial factor is the software design, which will mirror only the 
functional requirements that are articulated in the requirement analysis. These 
requirements shape the framework and capabilities of the software designed. This 
relationship has a critical impact on even the smallest change that has to be made after 
this early stage of development, and is one of the most powerful factors of cost and 
schedule. Overly optimistic assumptions of the total amount of software needed leads to 
initial delays, as demonstrated by various programs such as the F22 4 , FCS 5 and SBIRS 6 
programs. 

Software developers use a similar checklist 7 for developing hardware. It 
prepares for design reviews of the system to verify their compatibility and testability. The 
software development environment is not mature enough to allow for common 
development practices and compared to the hardware sector, has few verified and suitable 
tools. However, there has been significant progress since the early days of software 
development. Modem software languages allow more flexibility, focus on functional 
needs instead of lines of code, and increasingly support an open architecture that is 
advantageous for maintainability and sustainability of embedded software in major 
weapon systems 8 . 


4 F22 Raptor, first supersonic stealth fighter of the USAF. 

5 FCS, Future Combat System of the U.S. Army. 

6 SBIRS, Space Based Infrared System. 

7 A typical checklist for this purpose is illustrated as an example in Systems Engineering And 
Analysis, Fourth edition, Blanchard/Fabrycky, page 730, Figure B.2. 

8 See also Joint Strike Fighter Air Vehicle C++ Coding Standards For The System Development and 
Demonstration Program, December 2005 at 

http://www.isf.mil/downloads/documents/JSF AY C%2B%2B Coding Standards Rev C.doc Last 

accessed February 2008. 
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b. Lack of System Thinking 

The expression Tack of system thinking’ refers to two different major 
aspects: we try to make sense of reality applying filters and making assumptions. This is 
a helpful and vital tool for dealing with every-day life. However, these experience-based 
assumptions incorporate delays, biases, errors and other imperfections. It is necessary to 
be aware of this. To avoid those inherent mistakes, a vast amount of feedback 
possibilities must be implemented. Even then, there will be misperceptions of the 
feedback 9 . Unfortunately, false assumptions occur often when they rely on limited 
experience alone. 

As researched by Scott Pious 10 in 1993, overconfidence is a common and 
catastrophic problem in decision making. His research indicates that judgements are 
rarely accurate. To gain confidence, assumptions must be corroborated by as much data 
as possible. However, data bases alone are not sufficient to avoid errors completely 
because they are limited and often allow ambiguous interpretations. Desire for change 
within a system might not become true simply because it cannot replicate the full 
dynamic complexity 11 of the system. This fact is a limiting factor to the success of any 
conclusions and recommendations made in this report. Nevertheless, if consequences are 
thoroughly investigated, the recommendations will be of some use to improve the 
existing difficulties if they are carefully applied. 


9 See also Business Dynamics, Systems Thinking and Modeling for a Complex World. Sterman John 
D., p. 27, Table 1-4 that shows numerous studies that have documented this observation. 

10 See also Business Dynamics, Systems Thinking and Modeling for a Complex World, Sterman John 
D., p. 272, Overcoming Overconfidence. 

11 See also Business Dynamics, Systems Thinking and Modeling for a Complex World, Sterman John 
D., p. 22, Table 1-3 that illustrates our difficulties to understand a system as a whole entity. 
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c. Lack of System Engineering Principles 

As demonstrated in various acquisition programs 12 , system engineering 
principles and models 13 are key tools for successfully developing a system. These 
principles however, need to be applied continuously, require strict oversight and good 
communication among the different stakeholders, and a chief system engineer who is 
experienced in the segment of the system that is to be developed. The steady and 
determined application of systems engineering principles and tight oversight is even more 
essential since the lack of software requirements and system thinking are common themes 
in failed projects 14 . One example of rushing into CDR and production is the SBIRS high 
program. According to a brief in class by a former student involved in the program, the 
program went into CDR with immature software (only about 50%) of the total amount of 
software produced and immature technology of subsystems still a problem at production 
start. System engineering principles are crucial in developing designs that accommodate 
current and future software and hardware attributes within a complex development 
environment for complicated system-of-systems architectures. On average, major weapon 
system programs software development tends to require almost twice the scheduled cost, 
and more than 220 percent of what was estimated at the start of the program 15 . The 
demand for cutting edge technology in almost every major program is one cause of this 
situation because of its associated uncertainties and risks. 


12 For example SSGN Trident conversion program. Aircraft F18 E/F upgrade program. Link 16 
program. Unmanned aerial vehicle Predator A MQ-1 / B MQ-9 program. 

13 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 131, Figure 
5.6. 

14 See also Developing Software Requirements Supporting Open Architecture Performance Goals in 
Critical DoD System-of-Systems, Naegle Brad, p. 10. 

15 See also General Accounting Office, Defense Acquisitions: Stronger management practices are 
needed to provide DoD's software-intensive weapon acquisitions. Report to Committee on Armed Service, 
U.S. Senate, March 2004, publication no. GAO-04-393,7. 
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d. Management Issues 


Management issues in the software development segment are often related 
to underestimations of the amount of work needed to accomplish the tasks. It is better to 
start with too many programmers and reduce the numbers later on because adding 
personnel late in the process is usually detrimental as different publications on this 
specific topic 16 show. 


e. People Issues 

Software development for complex weapon systems is different from 
software development for commercial businesses. The main defense contractors have 
typically employed people from one pool of programmers for their projects. This has two 
advantages: they are already familiar with the special demands of the Department of 
Defense environment and are also aware of special regulations and rules of the prime 
contractor. This means they can be easily integrated into the working environment. Other 
contractors discovered this phenomenon and have struggled with basic applications due 
to the lack of qualified software developers due to the competition for the same developer 
pool 17 . 


/. External Forces 

Software development is a sensitive area, but crucial for the smooth 
functional performance and integration effort 18 of subsystems and their components. 
Disruptions in software development, like adding new requirements late in the 


lf) See also The Dynamics of Software Project Staffing: A System Dynamics Based Simulation 
Approach, Abdel.Hamid Tarek K„ 1 F.F.F. TRANSACTIONS ON SOFTWARE ENGINEERING, Vol. 15, 
No.2, February 1989 and The Experience Trap, Sengupta/Abdel-FIamid/Van Wassenhove, Plarvard 
Business Review, February 2008. 

17 As for example Northrop Gmmman Ocean Systems had to leant when they allowed a subcontractor 
use an old software application to develop the Advanced Seal Delivery System, ASDS, a program that was 
cancelled due to multiple shortcomings later on. 

18 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 106, Figure 
4.7. 
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development process, or software immaturity due to poorly defined requirements, will 
lead to major delays in schedule and massive cost overruns 19 . 

External forces are a permanent and serious challenge to the software 
development segment of acquisition programs. A lack of understanding of relationships 
within the process, requirement additions, funding changes, schedule pressures, and 
interference from political interest groups can have a very negative impact on acquisition 
programs, even if solid system engineering and acquisition management processes are in 
place. A major concern in the software development sector is a poor understanding of the 
processes that differ from the rest of the system’s development. As an example, 
successful software development depends heavily on small incremental steps and a high 
demand for testing. This causes significant confusion and is often misunderstood 20 . 
Software is different in contrast to developing a new, cutting-edge hardware component 
or technology; non-software development is typically not the problem. Software depends 
basically on lines of code that are necessary to achieve the desired function, but systems 
are complex. It is rare that a complex system works as desired when first developed, and 
requires significant testing to ensure reliability and safety aspects expected from weapon 
systems. This also applies for programs that are costly and do not have any failure 
tolerance at all 21 . Political stakeholders are sometimes not aware of the additional risks 22 
they impose with changes in schedule, funding, and requirements, or the related impact 
on the warfighters and the taxpayers in the long run. 


19 A good example is the SBIRS program that had to take 94 requirement changes after preliminary 
design and went into detailed design with less than 50 of the software accomplished. 

20 See also Developing Software Requirements Supporting Open Architecture Performance Goals in 
Critical DoD System-of-Systems, Naegle Brad, pp. 11, 18. 

21 Good examples for such systems are satellite systems, space programs like the Space shuttle 
because any failure might result in complete loss of the mission or system. 

22 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 711, Figure 
19.12. 
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2 . 


Shortfalls in the Acquisition Process and Management Segment and 
Their Impact 


Figure 2. Major shortfalls areas in the acquisition process 



a. Organizational and DoD Specific Structural Problems 

In this section, typical problems within the acquisition processes and 
acquisition environment are explored in more detail. The factors here are more numerous, 
but can have the same devastating effects on programs as those imposed during software 
development. 

The structural and organizational framework of the DoD environment 
provides ample opportunity to implement changes, improve efficiencies, clarify 
responsibilities, and balance supervision and control. However, change is difficult to 
implement, especially in such a large and interdependent structural framework like the 
Department of Defense 23 . Therefore, any change will always face considerable resistance 
and require significant time before it is fully implemented and embraced. 

The obligation to reduce personnel costs in the DoD environment has 
deteriorated the acquisition experience base as well as knowledge redundancy. 
Unfortunately, the loss of knowledge was far greater than the reduction of the 
workforce 24 . Two areas that were crippled by this effect were the general acquisition 

23 See Organizational Behavior, Me Shane/von Glinow, Me Graw-Hill/Irwin, New York 2007, chapter 
14. 

24 As stated during MN3304 class, Yoder Cory. 
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workforce, and within this community, the contracting specialists. Experienced personnel 
were required or given incentive to leave; the professionals remaining had to deal with a 
large and increasing number of programs. Time is precious and there are not enough 
employees to properly analyze the programs in great detail. This leads to an increased 
danger of ‘playing the system’ and causing damage to the trust of the regulations in 
place 25 . 

In addition, frequent cost and schedule overruns of many programs did not 
result in a deeper investigation of their causes. Rather, it resulted in rapidly evolving new 
regulations and supplements to the Federal Acquisition Regulation (FAR) and other 
directives. For those trying to operate within the acquisition processes, this made work 
even harder. The regulatory additions addressed the symptoms of the problems instead of 
the cause. The envisioned workload reduction after the Cold War era was supposed to 
allow smaller Services and a reduced civilian workforce through a decline in transactions 
and smaller programs. Fess need for oversight was also expected, but neither ever 
became reality. The increased number of regulations and the reduced number of 
surviving contractors capable of delivering the major weapon systems made more 
oversight mandatory. A flood of new regulations attempted to address the problem that an 
inexperienced workforce faced as schedule pressures and work overload increased, which 
triggered more compliance effort, that led to even more cost and schedule overruns. 

Program Managers (PMs) willingly contribute, more or less, to the 
problems. Because their role is to successfully complete the program, they have no 
interest in revealing its actual performance, especially if that performance is not viewed 
favorably. Because they want to keep their program alive, they feel pressure from their 
service to bring their program to deployment so that the new system is not lost. However, 
the PMs cannot be primarily blamed for this effect; their behaviour is consistently 
rewarded and enforced. Even if this was not the case, the necessary and accurate 
information about real estimated costs of a program and its life cycle would be hard for 
them to accurately estimate. This is because the contractor is disincentivized in admitting 

25 See also Developing Software Requirements Supporting Open Architecture Performance Goals in 
Critical DoD System-of-Systems, Naegle Brad, p. 13. 
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the difficulties of accomplishing the program within the cost and timeframe. He will wait 
at least until production until he comes up with the full truth and more or less reliable 
cost of the program because before production he barely makes any money at all on state 
of the art weapon systems. He fears that otherwise, the program will be reduced 
considerably or even be terminated. This fear is understandable. An example using 
immature technology even in the production process was the Advanced Seal Delivery 
System associated with the SSGN conversion program. Immature technology for 
subsystems like the batteries led to a lot of delays, cost overruns and even more 
concerning to a fatal accident during testing. This fact caused a cancellation of the ASDS 
program and reduced the capabilities of the converted submarines. 

The Services themselves are major sources of initial misinformation that 
feed this system. Quantities needed are exaggerated in expectation that these numbers 
will be cut by politicians or budget constraints. Contractors estimate cost and profit based 
on these numbers and are quick to rapidly accelerate unit costs as planned quantities are 
reduced by the Government. Members of Congress do not use the correct tools to 
terminate these unhealthy relationships. They cut funding and influence major programs 
for regional and political reasons. This behaviour and bias in favour of regional revenues 
and influence adds another level of inefficiency to the existing problems of the 
acquisition process. 

Accountability for results is low among the services and PMs because 
turnover rates are high and people change positions every few years. Most of the time, 
they do not manage a program for even one complete phase of development. 
Accountability is even lower among politicians influencing the decisions and contractors 
taking advantage of this reality because it is hard to relate actions taken to the overall 
outcome of inadequate actions, and influence is hard to prove. The Joint Capabilities 
Integration and Development System 26 (JCIDS) introduced yet another source of 
inefficiency to the acquisition process. The goal was to achieve more ‘jointness’ to all 
programs, reduce redundancy among the services, and foster interoperability within the 

26 For a detailed historical background and discussion of the JCIDS process see U.S. military Program 
Management, Garret, Gregory A. / Rendon, Rene G., Chapter 2. 
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forces. JCIDS is a top down process, but the expertise that is really needed is strongly 
related to the experience of Combatant Commanders, who are not well versed in the 
JCIDS or acquisition processes. 

Other important factors are organizational structures of the DoD and the 
acquisition workforce itself. They reflect the needs to handle the tasks in which they were 
designed. We can use organizational structure theories to investigate aspects of 
suitability, function, adaptability, and general fit. According to Mintzberg, 27 
organizational structure can be related to the structures efficiency in dealing with 
uncertainty in an environment that is characterized by stability and complexity. There are 
two ways to produce undesirable outcomes. One is to use the wrong structure for the 
environment, and the other possibility is to use the wrong people or processes. Both 
observations can be made by examining the structures on different levels of the DoD 
environment and performing a stakeholder analysis of all the key players in the 
acquisition process. The results of this examination will make clear a few of the less 
obvious interdependencies and relations within the complex structure of the acquisition 
and DoD environment. 

b. Legal Restrictions 

The amount of legal restrictions 28 and regulations is a barrier to an 
efficient acquisition processes. The rules imposed provide guidance but current legal 
restrictions are so numerous that they actually hamper the flexibility needed in a 
changing acquisition environment. Because there are so many laws and regulations, some 
of the opportunities of the current legal framework are not fully understood or followed 
by the acquisition workforce. A costly example of this fact is the lack of understanding of 
the implications of subpart 13.5 within the FAR dealing with simplified acquisition 
procedures for commercial items up to a certain monetary threshold. This section was 
implemented to reduce transaction costs, ease acquisition processes and reduce 


27 Organizational Design: Fashion or Fit, Henry Mintzberg, Harward Business Review 1981. 

28 A small excerpt from all legally binding documents is presented in Table 3, 4 and 5. 
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acquisition time pressures 29 . Statuaries and regulations and continuous changes to the 
FAR are so enormous that the acquisition workforce has trouble keeping up with and 
correctly implementing them. In addition, many laws and regulations are designed to 
implement desired societal or democratic principles, not improve acquisition efficiencies. 
In addition to difficulty to keep up with the flood of laws, rules, regulations and 
directives these documents sometimes restrict competition among the few global 
contractors that are globally available to produce a major weapon system. This is 
unfortunately and partially contradicts the goals of the FAR as the FAR principles state 
that the amount of competition should be maximized whenever possible 30 . One example 
for legally restricting competition opportunities is the Buy American Act that hampers 
full use of globally available technology and contractors. 

c. Lack of Communication and Oversight 

Many acquisition programs suffer from a lack of communication and poor 
oversight. The fear of losing a program or admitting to an unexpected negative event has 
a negative influence on the communication of problems and solutions that make a 
program successful; errors that are easily resolved in their early stages accumulate until 
they become serious. In some cases, the program must be cancelled due to this 
accumulation. The schedule and costs needed in fixing these issues may become a major 
threat to the program. 

d. Management and People Issues 

Creating a new system requires significant management, coordination, and 
communication among many different people. This can become an issue if there are 
personal barriers that slow this process. Involved parties should be professional enough to 
overcome these issues, but this is not always the case. 


29 As stated during class MN3304, Yoder Cory. 

30 See also FAR, subpart 1.102 Statement of Guiding Principles for the Federal Acquisition System. 
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e. Lack of Understanding and Changing Requirements 

A lack of understanding can be caused by poor translation or 
misunderstanding, and is a critical issue to the overall success of a program. 
Requirements that are wrong, unclear or misunderstood can be fatal to the success of a 
program. Requirements not defined clearly and agreed upon will inevitably lead to 
warfighter attributes that cannot be met by the system and will likely be considered 
inadequate. The relationship is well characterized by the following quote: “Why did we 
build the wrong thing? Because we could not get the requirements right.” 31 The same 
underlying problem was articulated earlier with a different twist by Yogi Berra: “You got 
to be careful if you don’t know where you going, because you might not get there!” This 
is unacceptable. Sometimes the missing function cannot be easily implemented, if at all, 
into the system if it is discovered too late in the acquisition process, such as during live- 
firing and testing. Faults during the first steps of the process will cause irreversible 
problems in scheduling, cost, and performance in the new system. 

Stakeholders also contribute to this area of problems. During the different 
stages of the acquisition process, when the system is beginning to coalesce, stakeholders 
add or change system requirements. This practice is as bad as it is common. The 
operational requirements were formulated according to the initial need to close the 
capability gap. The requirement analysis should have addressed all requirements that are 
needed to achieve this goal Therefore, there should be no necessity to add new 
requirements unless specifically driven from unforeseen changes in the threat or to take 
advantage of a truly compelling opportunity. 

The real need for requirement changes must be related to the change in the 
gap that has to be closed. This rarely happens. Most of the time, additional or augmented 
requirements have nothing to with the operational environment of the new system. These 
changes entail redundant capabilities, unnecessary items, and irrelevant opportunities. 
These are serious threats to the program because they consume development time, 
integration efforts, software development interfaces, testing needs, and other unplanned 


31 As stated during class MN3309, Naegle Brad. 
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activities. They reduce the available budget needed to fulfil the essential requirements. 
The additional requirements are especially damaging if the new system was designed for 
a specific gap and the mission suddenly expands well beyond the initial requirements. 

/. External Forces 

Changes in law and policies, general budget cuts, or funding for specific 
parts of a program are a major impact on the success and efficiency of an acquisition 
program. Some changes are not predictable, such as rapidly evolving crises or threats that 
must be solved by adapting capabilities, missions, and funding. 

E. MORE DETAILED DISCUSSION OF IMPORTANT PROBLEM AREAS 

This section analyzes why requirements and external forces are of special interest. 
The findings of this analysis will identify recurring patterns that must be avoided in the 
future. The solutions to these patterns will enhance the chances for successful system 
development. 

1. Formulation of Requirements 

a. Operational Requirements 

Formulation of requirements applies to both hardware and software 
requirements. Both are generated from the operational requirements communicated by 
the user. This area needs special attention because every mistake in elaborating, 
formulating and translating those requirements into functional design will result in a 
function that is not represented correctly and further isolate functionality away from the 
user’s need. 

Why should the requirements be the first thing to start with if it is so 
difficult to get them correct? The answer is simple, but difficult to accomplish within the 
complex acquisition environment of the DoD: requirements are the boundaries of what is 
needed, and also describe all necessary functions that must be accomplished. From this 
starting point, the rest can be deduced. 
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An example might clarify this difficult point. Let us assume there is an 
island state and because of the proximity to an influential and powerful neighbour state 
this island feels threatened. The island state decides to develop a “protection system” to 
protect itself. Up to this point everything seems to be logical and easy to understand, 
however, this is typically where difficulties begin. The protection of the island state 
represents a capability gap that must be closed at the start of a major acquisition program. 
It is easy to go awry attempting to plan the ‘protection capability’ efficiently and 
affordably without unnecessary redundancies; there are many opinions about the “right” 
solution to this problem. Operational requirements are useful in deciding which way to 
proceed. They can help describe an optimal solution because they are free of biases. The 
requirements focus only on closing the capability gap according to the operational 
parameters of the state’s special situation. A parallel process that is needed for the 
successful creation of the new system has begun. It faces four basic challenges at this 
point: 

1. The operational requirements must be correct. This requires significant 
communication, clarification, and feedback between the developer, customer, and the 
other stakeholders. Incorrect assumptions or requirements will produce additional and 
unneeded capabilities with negative impact on cost and schedule, or even worse, will not 
close the threat gap as a whole and leave the country vulnerable. This is anything but 
desirable. 

2. The requirements then have to be clearly defined and stated. While 
simply stated, this is can be incredibly complicated process. There are likely many 
interpretations of the term ‘protection’ that need to be explored. 

3. All stakeholders involved must understand the requirements. Precisely 
communicating a particular requirement with high confidence that the communication 
was well understood is not an easy task. Again, the requirements will likely be subject to 
interpretation despite all attempts to clearly communicate them. 

4. Requirement changes and additions must be kept to a minimum. All 
necessary requirements should be fully identified, correctly stated, and implemented. 
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These four pitfalls must be overcome to enter the next step: translating the 
operational requirements into functional requirements. 

b. Functional Requirements 

The purpose of functional requirements is to identify functions that are 
needed to satisfy the operational requirements and create warfighting capability. In the 
aforementioned example, functional requirements would be ‘protection’ against air 
invasion, missile threat, amphibious landing etc., depending on the operational 
environment. Notice that the functional needs still focus on the need, or in other words, 
what must be done, not how this particular goal is achieved. The functional requirement 
analysis links every requirement to one or more functions that must be met to satisfy the 
need. This traceability is necessary to address all needed requirements and prevent 
redundant capabilities that are already accessible. This is essential to develop a system 
that fits the task and is efficient and economically reasonable. The functional analysis 
also investigates the best approaches, such as hardware, software, or manpower for 
completing functions; it identifies support and maintenance needs; and it gives the new 
system a rough skeleton consisting of requirements and structure. 

2. Poorly Defined Requirements 

Requirements that remain unclear invite interpretation, errors and rework once the 
mistake is discovered. Defining the requirements concretely is the key to enabling the 
right follow through of activities in the development process. Poorly defined 
requirements lead to deviations within the system, causing inefficiencies, frustration for 
customers and contractors, and endangerment of the required system performance. 
Unclear requirements are a major threat to the development of a good acquisition 
strategy; if assumptions are incorrect, they lead to wrong decisions and poorly defined 
objectives for a contractor’s legal obligations. 
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3. 


Late Changes in the Acquisition Process 


Late changes and requirement creep are inevitable and endanger the success of a 
program. They occur frequently without being based on changes to the operational needs. 
Politicians, the services, and the users have to understand that adding a requirement 
means significant reengineering of the software component. Modem weapon systems are 
sophisticated; their physical design, software programs, multiple interfaces, and 
integration needs are not well suited for late changes because late changes can drive a 
drastically different design or solution causing significant reengineering and scrap of 
work already completed. Insisting on additional requirements often leads to integration 
problems, high costs, and poorer system performance. In the worst case, the system may 
be rendered complete uselessness 32 , but unfortunately, understanding of the probable 
impacts of late changes is not widespread. 

4. Differences in Testing Requirements 

Testing is expensive. This valuable part of evaluation in the acquisition process is 
often underfunded because the benefits of adequate testing are not fully understood. 
Thorough testing is not a luxury of the program. It provides evidence that requirements 
have been met, the system works reliably and safely under all conditions. In addition to 
these aspects testing creates confidence, and gathers data that is essential to future 
capability technological advancements. 

5. Lack of Mutual Understanding about Operational, Support and 
Maintenance Needs and Schedule 

The government provides funding for new systems to close capability gaps and 
encounter threats to the country. It also expects a system to survive as long as it is needed 
for its task. System engineers plan for the system as long as a customer he intends to use 
it. 


32 A program that suffered from the last three segments was the A12 A Avenger II. The program was 
cancelled after only three years. At that point the aircraft was already two years behind schedule, 1,3 
Billion dollars over cost and had 8000 pounds overweight. 
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Sometimes, these life-cycles are not aligned at their beginning. This causes cost 
problems in the use, reduced availability and life-cycle of the system. Operational 
requirements or conflict may cause a system to be used more than expected, which causes 
accelerated wear and tear, higher maintenance support efforts, and operational costs 
during wartime. These circumstances cannot be planned for, but cost expectations for 
prolonged life-cycles and excessive use can be calculated and predicted. The government 
and services often have goals for intended economic useful life spans, but do not 
communicate them to the contractor. This may be unintentional; they forget to update the 
information before the program starts. It may also be intentional; they know that longer 
life-cycles go hand-in-hand with higher system-costs. As already stated, system and life 
cycle costs can determine whether a program is initiated, as well as the total planned 
number of systems to acquire. This view is short sighted; the contractor should be 
provided the expected system life-cycle, especially if it might be considerably longer 33 . 
The following depiction shows that this is not rare. Most systems are designed for an 
average life-cycle of about 25 to 30 years. 


33 This basically applies to all aircrafts and many other systems in use, see examples on table 1 below. 
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Table 1. Aging Systems Cause Supportability Issues 


Aging Systems 
Cause Supportability Issues 



HEMTT 

SSN688 - 

F-15 - 

F-14 - 


CH-47 
M-113 - 
UH-1 - 
KC-135 — 
AIM-9 — 

C-130 - 

2.5 Ton Truck — 
B-52 - 


44 yrs 
56 yrs 
51 yrs 
41 yrs 
71 yrs 

59 yrs 
49 yrs 


86 yrs 
72 yrs 

79 yrs 
67 yrs 
94 yrs 


1940 1950 1960 1970 1980 1990 2000 2010 2020 2030 2040 


Source: MN3331 lecture slide, Professor Rene G. Rendon, NPS 


The point is, if a new system stays in service considerably longer than it was 
designed for, there is a major impact, especially on the Operations and Support (O & S) 
life-cycle costs (LCC) and supportability 34 expenditures. If the contractor is aware of 
planned system economic useful life, the system design and design for supportability will 
likely be properly architected. In the long run, this will lead to a more robust design that 
allows for further upgrades. This can be an essential factor for controlling the costs of 
program upgrades, which can be planned for technical refreshment, mid-life conversion, 
or other life cycle considerations. Communicating requirements and expectations for 
extended life-cycles can save significant operational and support funding over the 
extended life cycle. 


34 See also Systems Engineering And Analysis, Fourth edition, Blanchard/Fabrycky, p. 542, Figure 
15.10. 
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6. Funding of Programs 


a. Budgeting/F unding 

Funding for acquisition programs is a complex process, burdened with 
numerous laws, policies, and other guidance documents. It is also vital to the program’s 
survival. 

Budgeting and the acquisition process are not aligned, and are driven by 
several factors. The cyclical budgeting process schedule is fixed, as required by law. 
Contrary to this, the schedule of an acquisition process is closely related to ongoing 
developments. These different methods do not mesh well. 

This problem is addressed, in part, by multiple years of identified funding. 
However, to determine how much money is available for a program, several numbers 
must be considered and calculated: the amounts that are available from the different years 
of funding, how much has already been spent, and how much is actually needed for 
successful completion. This system works well for accounting and control purposes, but 
is not good for program flexibility and overall performance of the acquisition programs. 
When there is no funding available, and the PM cannot secure additional funding, a 
program remains idle when it could otherwise be progressing towards completion. 
Another problem arises when money that is available has been specified for a specific 
purpose, known as the “colors of money,” 35 and those specified purposes are different 
than the needs of the program. This leads to an insufficient amount of funding to continue 
development because of the use restrictions. Navigating the myriad of funding laws and 
directives requires a significant amount of management, reducing the amount of time 
PMs have to manage the system’s development. 

This legal background causes another challenge. The preparations for the 
beginning of an acquisition program must be finished early enough to fit into the fixed 
cycle of the budgeting process. Pressure from the services to get programs started and 

35 The expression “colors of money” refers to the fact that any funding by law is determined by 
purpose, time and amount. The purpose is the related appropriation, often referred to as color of money and 
has its origin in Title 31, USC, which is also sometimes referred to as the “Colors of Money” law. 

21 



underestimated preparation time, for things such as requirement analysis, sometime result 
in a program that is rushed. The haste to begin a program is the result of significant 
pressure: either the program starts immediately or never. The perception that deficits can 
be fixed at later times is almost always wrong; life-cycle costs that are overoptimistically 
low improve chances of initial funding for programs. Over time, the needs and practices 
described in the paragraph above have resulted in interesting and malicious side-effects. 
Two common side-effects are burden shifting 36 processes and the implementation of a 
misleading reward system 37 . Both have a negative impact on the overall accuracy and 
trust of the acquisition process. 

F. ESSENTIALS OF SOFTWARE ENGINEERING AND ACQUISITION 
PROCESS MANAGEMENT REQUIREMENTS 

1. Software Engineering Requirements 

The crucial needs of software development are often misunderstood. Clear and 
well stated requirements are an absolute must for the success of any major program 
involving software. This applies to the overwhelming majority of modern systems as they 
are increasingly software-intensive. Service software has become an elementary part of 
virtually every program. The need for clearly communicated and addressed requirements 
covering all functional, interface, and all current and envisioned interoperability needs 
are vital to effective and efficient software development. 

Directly related to this need is a stable developmental environment that allows the 
identification and establishment of a framework that the software and system can operate 
within. As systems become more sophisticated and complex, systems within systems 
become more important. These factors are major schedule and cost drivers and dependent 
on software engineering. The keys to success therefore, include significant early work in 


36 See also Systems Archetypes Basics, Kim Daniel H. and Anderson Virginia, Pegasus 
Communications, p. 25. 

37 See also On the folly of rewarding A, while hoping for B, Academy of Management Executive 1995 
Vol. 9 No. 1. 
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requirements analysis, software development, and effective management to minimize 
changes to functional requirements and framework aspects. 

One pitfall is inadequate predictions of the amount of software that will be needed 
during early system development. Coding of the software itself is rarely a problem, but 
late requirement and operational framework changes are time consuming, costly, and risk 
not being incorporated during later stages of development. Software development is very 
expensive during the early stages of development (up to 60% of the overall software 
development cost or more), and can be compromised by rework resulting from poor 
requirements analysis, resulting in significant cost growth and schedule slips. 

2. Capability Requirements 

Capability requirements are an important factor of system design and are essential 
for a sound system engineering process. Capability requirements are increasingly 
expressed in terms of performance characteristics and metrics. Together with functional 
requirements and operational needs, they shape the preliminary and final design of a new 
system during trade-offs within the system engineering process. Identification, 
formulation and correct prioritization of these requirements are key in developing the 
overall abilities, optimizing strengths, and limiting weaknesses of a new system. 
Weighing, examining, and balancing tradeoffs in the system engineering process is part 
of the analysis of alternatives. 

The problem is poor communication among the services regarding the functional 
and operational requirements. They do not focus enough on tradeoffs and their 
consequences on the system design. Instead, the responsibility lies in the contractor’s 
system engineering process, whose results depend on the interaction between IPTs 38 . 


38 See also Developing Software Requirements Supporting Open Architecture Performance Goals in 
Critical DoD System-of-Systems, Naegle Brad, pp. 13-16. 
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3. 


Safety Requirements 


Safety requirements of new systems repeatedly represent a common pitfall for the 
acquisition process. Sometimes, safety requirements are forgotten, poorly communicated, 
or assumed to be a software engineering environment. 

Unfortunately there are a lot of programs that tell a different story. A system is 
safely handled when data transfer is secure and is robust against electronic 
countermeasures, hacking, and spoofing. These needs must be satisfied in an environment 
where equipment used by ground forces has a high risk falling into the hands of the 
enemy 39 . 

4. Interoperability and Interface Requirements 

The operational framework is the most influential factor in determining the 
nature, complexity, and number of interfaces and interoperability needs. The operational 
environment in modem warfare is very complex and inhibits joint aspects, at least at the 
national Services level and below. More often, another level of complexity l ik e 
interoperability with allied forces, is created by the net-centric nature of command and 
control systems and data processing systems, which aid the decision making of Combat 
Commanders and political leaders. The recipe for sound interoperability and reliable, 
robust interfaces is the selection of a correct work sequence. The easiest way to achieve 
this goal is to begin laying out the operating framework of the new system. The goal of 
the framework is sometimes not completely communicated, verified or accurately 
examined, which leads to problems in integration, interface suitability, and causes time 
consuming and costly design changes late in the acquisition process. Once the complete 
requirements framework is established, the design of individual components, subsystems 
and systems-of-systems within this framework becomes easier and less risky. 
Interoperability aspects and interfaces become more transparent and obvious; the amount 
of misinterpretations and unidentified needs are considerably reduced. The numbers of 
systems or system-of-systems that must interface in the depicted operational environment 

39 See also Developing Software Requirements Supporting Open Architecture Performance Goals in 
Critical DoD System-of-Systems, Naegle Brad, p. 24 
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and network sometimes face the challenge of incorporating legacy systems and 
equipment that was not designed for upgradeability or interoperability within the 
operational framework of modem warfare. Although most of the newer systems use an 
open-system-architecture to allow future changes, as conceivable in a significant time 
horizon, some of the legacy systems are difficult to integrate at all, or need significant, 
expensive redesigns in order to adapt to current standards. This is evident for every 
system incorporating only a small amount of software consisting of obsolete or 
unsupportable program languages, or simply did not allowing for extensions of relatively 
simple features like more throughput and memory. 

5. Upgrade Requirements 

There are tools and processes available that help to identify and determine various 
needs for software development. The Modular Open Systems Approach 40 helps to 
identify required interfaces. System engineers define areas where software support is 
needed to achieve system performance that can not or should not be represented by 
hardware. Modelling and simulation tools and software developing programs help to 
illustrate the complexity, total amount of software needed and how it might look like. 
This allows Program Managers and contractors to evaluate how suitable the software will 
be for the requirements stated and the amount and size of upgrades that might be needed 
over the life-cycle of the new system. The Modular Open Systems Approach (MOSA), 
consequent use of system engineering processes and a great variety of available software 
programs help to define how complex the new system will be. This allows system 
engineers, Program Managers, contractors also how complex the software package will 
be that is needed to satisfy the needs for interoperability, interfaces and upgradeability for 
the new system. The standards and metrics for software development do not match those 
of hardware. However, compared to the 80s and 90s, there is a better understanding of 
software development’s needs and underlying processes. Examples of this are the older 
metrics of software lines of code (SLOC), which become increasingly replaced by 


40 See also “Using a Modular Open Systems Approach in Defense Acquisitions”, Dr. Rene Rendon, 
pp. 17-19. 
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metrics of functional points that are more meaningful. Quality of software development 
has become vital to the interaction of information and first-move abilities on the 
battleground. 


6. Life-Cycle Requirements 

Software development and requirements have an important impact a system’s life- 
cycle. Software requirements are likely to change over the life-cycle of the system. If a 
good software developmental process is in place, this should not be an issue, but their 
consequences can become one if not considered at the start of a program. 

The military often uses their systems over an extended life-cycle. This is different 
from the commercial world, where special and operational availability needs lead to 
expensive systems. 

Software development does not end with the delivery of a new system. There is 
always the need to adapt to new operational aspects, lessons learned by the users after 
testing, suggestions for improvement, new technology, and changes in interoperability. A 
second set of common challenges for software requirements relate to the supportability 
and maintainability of the software. The software language used, proprietary rights of the 
software to develop the new system, and costs of maintaining the complete life-cycle are 
sometimes not given enough consideration. This leads to repercussions for the overall 
life-cycle expenses, security needs of the software, updated availability, restrictions for 
full and open competition, and other factors. Long term access to the development codes 
for new software, proprietary rights, and security aspects must therefore be a mandatory 
consideration of all programs that use embedded software or software intensive 
applications. 

G. ACQUISITION PROCESS & MANAGEMENT REQUIREMENTS 

1. Capability Requirements 

Capability requirements are not only of crucial importance for software as already 
described earlier. All requirements that try to describe the capabilities of the new system 
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are extremely sensitive for the overall achievements and operational success of the new 
system. These requirements should be performance based to allow a maximum of 
contractor creativity. They also should be related to metrics that can be easily evaluated 
and verified during developmental, operational and life-firing testing as the program 
moves towards fielding. If stated and prioritized correctly these requirements define the 
suitability and effectiveness of the new system and will contribute largely to its overall 
performance. Necessary trade offs have to represent the priorities of the customer and 
should be verified as decisions are necessary to shape the design and best solution to 
close the detected capability gap. All design changes with the exception of safety needs 
should be made prior the critical design review as late changes have a huge negative 
impact on cost and schedule. 

There are two decisive aspects that will have a major impact on the overall cost, 
performance and suitability of the new system. First, all requirements must be directly 
traceable to functional or operational needs. Second, the user must be aware of how 
different prioritization of those two sets of requirements interacts with the system 
engineering process during the design tradeoffs, influencing cost, performance, and 
suitability of the system as a whole. Chain of Command, users, technical, operational 
experts, logistical experts, contractors and IPTs must agree before developing a new 
system that addresses all requirements and delivers the best economical solution possible 
to the warfighter. The overall suitability and performance of the system are compromised 
by too many opinions on the importance of single requirements. This can also lead to 
unnecessary costs. 

The method of current requirement generation gives more weight to this 
argument. The top-down Joint Capabilities Integration & Development System (JCIDS) 
and Joint Requirements Oversight Council (JROC) do not include enough input from the 
Combatant Commanders regarding functional and operational needs for a new program. 
These inputs are not included in the acquisition process until too late, when they lead to 
requirement, software, and design changes. This process is inefficient, expensive, and 
adds an early and unnecessary risk in cost growth and schedule slips. Starting with 


27 



correct requirements and a relevant set of metrics for all functional and performance 
aspects of aligned system requirements is necessary for effective and efficient use of the 
available budget. 

2. Cost Control and Transparency 

Cost control and transparency are necessary for proper planning of the acquisition 
process and adequate stewardship of taxpayer. Congress, major defense contractors, 
Services, user communities, program managers and contracting experts agree that control 
and transparency of cost is necessary. 

There is a lack of enforcement procedures, proper group and individual 
accountability, and rewards for cost-conscience behaviour. As a consequence, regulations 
and tools are in place for a lot of partial processes attempting to maintain close cost 
control and visibility, but these are sometimes are not well-understood nor strictly 
followed. Unwittingly, these measures are neglected and at times, purposely 
circumvented to reach individual goals. 

3. Program Documentation Requirements 

The documentation for a major program has become a large burden in the 
acquisition process. Proper documentation is clearly beneficial and necessary, but it does 
hinder the acquisition process and contribute to higher program costs. This was especially 
true from the late eighties until the beginning of the 21 st century, before documentation 
efforts shifted towards electronic media, which is easier to change and does not incur 
high costs from reprints. Too much pressure on acquisition programs often leads to slips 
in proper documentation and any delay in documentation deliveries is usually a sign of a 
an over-worked staff struggling to keep up with the documentation requirements while 
managing the development of complex systems. 

4. Legal Requirements 

The flood of legal statuaries, regulations, and guidelines has become a definite 
challenge to the acquisition workforce. Program Managers must understand the variety, 
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and impact, of legal restrictions that apply to their program. They must work closely 
together with a diminished and less experienced contracting workforce to make sure the 
contract for the new acquisition conforms to all regulations and legal restrictions. The 
requirements have been developed by the IPTs to meet acquisition process goals, so that 
troops receive the best, affordable technical solutions as soon as possible. Now these 
requirements have to be transformed into a binding legal contract that is free of arbitrary 
formulations, contains all information needed by the contractor and incorporates all 
performance based metrics that are essential for the program. This is a challenging task 
and a decisive phase of the acquisition process. 

Especially when requirements or important performance parameters are not met 
by contractors, a contract can be the only leverage available to the government, so it 
needs to be clear. Developing necessary requirements and articulating them clearly to 
different stakeholders is very difficult, even if this process was well planned and 
successfully implemented into the request for proposal (RFP). A sufficient level of work 
breakdown structure (WBS) in the solicitation and contracting documents is just as 
important. Both processes need a sufficient schedule to support development success 
during the rest of procurement. 

Environments for the acquisition process are different. They span from stable, 
well planned system replacements, to contingency contracts. These environments can 
incorporate the need for complex systems, a research effort to make new cutting edge 
technologies mature enough to use for defense needs. Those environments include 
unstable and rapidly changing environments like unconventional warfare, terrorism and 
other new global challenges. . This is the reason why the legal framework must allow 
several approaches for acquisition procedures & processes, and several levels of 
competition and contracting methodologies to accommodate different situations. 

This does not only apply to current legal restrictions, but also to basic regulations 
and laws that hamper full and open competition. Analysis of alternatives (AoA) is one 
step that benefits from the system engineering process. This powerful tool for 
competition should not be compromised by legal restrictions if there are other options for 
addressing security and national interests. 
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5. 


Operational and Performance Requirements 


Realistic and measurable formulation of operational and performance 
requirements is vital to the acquisition process. Late design changes, bad trade-off 
decisions, delays, and cost and schedule overruns are almost inevitable if requirements 
are not fully formulated. For the purpose, there is no difference between traditional 
development, commercial off the shelf (COTS), or non developmental items (NDI). A 
wrong classification of COTS or NDI due to poorly defined or lack of requirements will 
have tremendous impact on the cost, schedule, and performance of the envisioned system 
acquisition. There were expensive and painful experiences during the aircraft T-45 and A 
12 procurement. 4142 

Realistic and measurable operational and performance requirements formulation 
is vital part of the acquisition process. Without enough effort on this basic early step, 
changes, late design changes, bad tradeoffs, delays cost and schedule overruns are almost 
inevitable and just a matter of time to occur within the program. There is no difference 
for this section whether we talk about traditional development or commercial off the shelf 
(COTS) or non developmental items (NDI). A wrong classification of a system as COTS 
or NDI due to poorly defined requirements or lack of requirements analysis will have a 
tremendous impact on cost schedule and performance of the envisioned acquisition of a 
system. 


6. Maintenance and Supportability Requirements 

The reality of acquisition reveals that if a program comes under funding pressure, 
whether due to cost or schedule overruns, there are usually two reactions. What is likely 
to happen first is a reduction of the program’s unit numbers 43 . 


41 See „The T45 T/S A Case Study”, GB 4450/MN4470. 

42 As stated in a brief on system engineering lessons learned from different programs during SI4011 
class. May 2007. 

43 See as an example change in production numbers for the F 35 JSF. 


30 



Table 2. Changes in JSF Program Purchase Quantities and Costs 


October 
2001 (system 

November 1996(program start) development start) 

December 

2003a 

(rebaseline) 

December 2005a(latest 
available data) 

Expected Quantities 

Development quantities 

10 

14 

14 

15 

Procurement quantities (U.S. only) 

2,978 

2,852 

2,443 

2,443 

Total Quantities 

2,988 

2,866 

2,457 

2,458 

Cost Estimates (Then Year $ in billions) 

Development 

$24.8 

$34.4 

$44.8 

$44.5 

Procurement 

Not available 

196.6 

199.8 

231.7 

Other 

Not available 

2.0 

0.2 

0.2 

Total Program Acquisition 

Not available 

$233.0 

$244.8 

$276.5b 

Unit Cost Estimates (Then Year $ in millions) 

Program acquisition 

Not available 

$81 

$100 

$112 

Average procurement 

Not available 

69 

82 

95 

Estimated Delivery Dates 

First operational aircraft delivery 

2007 

2008 

2009 

2009 

Initial operational capability 

2010 

2010-2012 

2012-2013 

2012- 





2015c 

Source: GAO Report 07-360, p. 5 


This strategy leads to less cost savings than anticipated due its negative impact on 
This is partially caused by spreading the fixed cost on fewer units but also by changing 
stress levels on material and increased times of operation for those units. This can lead to 
increased life-cycle cost and is unfortunately not given enough thought. Programs 
experiencing a substantial cut in production numbers typically lead to unit costs that were 
higher than originally envisioned 44 . This should never happen for short term savings. 
Cuts in procurement numbers are very common and can be an indicator of an 
incomprehensive and short-sighted view of these cuts’ effects on the acquisition costs 
because they have a major impact on the costs of long term lifecycles. Operational 
availability of the system will be lower as the flight hours on single units will be higher 
and result in more failures than envisioned. As there are fewer units used over a longer 
period as planned, maintenance turn-around time will be longer as higher stress is placed 
on the material. An insufficient level of spare parts might even be an additional 
consequence of an increased burden on the material. A significant cut in numbers 
combined with a false estimated reliability between failures can even lead to a temporary 


44 See Joint Strike Fighter program as an example (GAO report 07-360, p. 5, 7. 
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or constant unavailability of the new system. In addition to this problem the life-cycle 
cost for legacy systems might also increase due to higher maintenance cost as they have 
to be kept in service until a certain number of the new system replacing it is available. 

H. CHALLENGES & OPPORTUNITIES 

1. Flexible Budgets 

Changing the budgeting process and funding laws is difficult to achieve, but smart 
decisions in this area save taxpayer’s money and reap huge benefits. Some changes can 
be implemented over time if the impacts and consequences of the suggestions are 
understood and properly addressed. 

Sub-optimized practices and relationships contribute to the waste of resources and 
reward system inefficiencies. The schedule driven budget cycle must support the event 
driven acquisition cycle more functionally. This includes the necessary amendments to 
budgeting laws and procedures, which will eliminate waste in the current processes. 
There must be incentives for all stakeholders, including members of Congress, major 
defense contractors, the Services, and the acquisition community, to make the right 
decisions, encourage honest and accurate estimations, and reward the efficient use of 
taxpayer money. 

2. Higher Accountability for Services 

The Services must take more pride in their ownership of new programs. 
Warfighters need support throughout the procurement process in order to deliver a usable 
solution, or “best bang for the buck” systems. Because overall numbers decline and 
manpower resources become scarce, there must be enough capabilities to assign users to 
the different programs and involve them early. This also applies to Combatant 
Commanders, whose contributions in requirement generation, evaluation and testing are 
mandatory to quickly detect misfits, design miscues, and suitability issues. This is a vital 
role in the success of the program. 
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The current fight over different concepts and popular programs hurts the Services 
and users more than anything else. Once supplementary funding is deeply curtailed or 
eliminated, the distribution fight among the Services will intensify. The Services must 
understand that this behaviour is not helpful to anyone. Duplicate capabilities are a waste 
of resources and should be reduced or eliminated. The efforts to achieve the desired joint 
capabilities must be aligned. This would allow the Services to contribute their strengths 
and share the burdens and responsibilities of modem warfare equally. The solution is to 
stop fighting over resources. 

This competition over funding can appear to be driven by parochial interests 
rather than any real warfighter need. This mode of thought is counterproductive to 
achieving weapon systems that are flexible and capable enough to meet the future needs 
of net-centric warfare and increased interdependencies. The pride of the Services cannot 
come before the best interests of the warfighters and taxpayers in decision making. 
Increasing monetary pressures will be a decisive factor driving a development within the 
civilian and political environment into a healthier direction based on the real needs of the 
Services over time. 

3. Less Misuse of the Funding and Acquisition Processes 

The Services and their acquisition forces are the least powerful stakeholders in the 
acquisition process. Nevertheless, they are assigned responsibility whenever an error 
occurs in a procurement program. This is true no matter whether it is Congress cutting 
funding in an irresponsible way, contractors trying to maximize profits on an ambiguous 
contract, or if the user/combat developer communities are providing poor program 
requirements. 

The acquisition workforce itself has made the best of this situation inventively. 
There are many bad practices that can be observed throughout various programs. 
Program Managers and contractors start their programs with overoptimistic assumptions 
regarding their schedule and cost. Once the program starts and the first problems appear 
they are quite often ignored and not aggressively addressed. This happens because some 
contractors and Program Managers did not expect to deal with a difficult situation early 
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in the acquisition process and fear for their program. This tends to happen especially if a 
major problem surfaces at this early stage of the process that might result in a 
cancellation of the program or major cut to it’s funding.. Unfortunately, this causes the 
problem to arise later, when it is too late to solve or too costly to redesign. The contractor 
is not interested in disclosing the problem until production because the program might be 
cancelled early, and usually does not make any significant profit until the production 
phase. The result of this delayed fault detection and recovery is late design changes, 
which overruns cost and schedule. 

Program managers have learned how to get support for their programs, establish 
connections with members of the Congress. They know how to drain funding from 
programs that suffer for any reason or can not spend their appropriated funding within the 
given time constraints. While other, less experienced programs are hammered for cost 
and schedule overruns, program managers gain additional reserves for small uncertainties 
and glitches in their program. 

At the end of the fiscal year, every Program Manager prepares contingency plans. 
They include preparation of contracts they could sign immediately to spend money that 
other programs were not able to contract could not before the accounts expired. 

4. Better Quality for the Warfighters 

Every stakeholder should behave in the best interest of the overarching goal to 
achieve the best possible results for affordable warfighter capability. The goal of the 
acquisition process is to deliver the most suitable, capable, affordable, and current 
solution to the warfighter. This calls for robust designs resulting in high quality products 
that are easy to maintain, support and dispose of. Accurate requirements, incentives, and 
flexible rules and regulations are powerful tools that contribute to this task; small changes 
in attitude and behaviour can also make a significant difference in estimations of cost and 
schedule, and boost performance for the new systems needed. Aligned software and 
hardware requirements, and strategic partnerships among all stakeholders, will deliver 
better quality, more quickly, and at lower prices to customers. 
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5. 


More Trust in the System 


Re-establishing a flow of processes that are transparent and meet the goals of the 
acquisition process, the current debate over programs that are more expensive and 
prolonged than originally planned must be ended. Huge organizations like the DoD adapt 
slowly, and inhibit change. It is necessary that incentives, which are generally slow, do 
not cannibalize strengths as a price of change. 

I. CONCLUSIONS 

The generation and alignment of requirements for software and hardware for new 
major defense programs are complex processes themselves. Aligning requirements 
among the different stakeholders within an organization as large and diverse as the 
Department of Defense is difficult and requires the understanding of the stakeholders 
with regard to their contribution, role and responsibility in the acquisition process. Key 
stakeholders outside of DoD, like members of Congress, the Media, and Lobbyists make 
it even more difficult for the acquisition community to deliver effective and suitable 
capabilities to warfighters. Nevertheless requirements generation, implementation and 
verification will remain one of the major challenges for the future. It will be decisive to 
change current procedures to allow a better preparation of this essential work before the 
start and contracting of new programs. 

No new regulation, changed process, or single source can solve the challenges of 
this unique business environment. It will be individual stakeholders who will create a 
successful and efficient program. Their passion and supportive interaction is what will 
make a real difference. The acquisition workforce will need tools that are flexible enough 
to deal with long term planned replacement of systems, urgent battlefield needs, 
commercial items acquisition and contingency acquisition at the same time. The legal 
framework has to allow this flexibility, maintain contractor oversight and foster 
competition 

A variety of new, different approaches are discussed below in the 
recommendation section. Only a mix of the effort, honesty, willingness, and cooperation 
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of individuals in the acquisition process will create positive change. As an additional 
challenge, there is a common resistance to change in organizations. There are also 
tradeoffs in their organizational structure and ability to support attributes like efficiency, 
adaptability and creativity. The Acquisition workforce has to be big and experienced 
enough to deal with these challenges and should be allowed to operate in an environment 
that imposes as few legal restrictions as possible but enough guidance to focus on 
efficient use of taxpayer money and high quality products for their customers. This 
approach will increase individual responsibilities on one hand and accountability for 
decisions and actions on the other hand. 

J. RECOMMENDATIONS 

1. Software Requirements and Software Development 

a. Software Planning and Requirements Formulation 

Software planning and requirements formulation are a very tough tasks. It 
is common for the complexity of functional needs and environments to be partially 
unknown in the early phases of software planning. The formulation of requirements 
involves at least some insight into the actual coding language and processes. . This is 
important not so much which language is actually used for coding but to ensure the 
coding language is sate of the art and will be sustainable over the envisioned lifetime of 
the new system. The most time and money goes into configuring the architectural 
framework and laying out the software design this complex process to sort out the 
functional needs that will be represented by the software, needed interfaces and data 
flow, amounts, and interdependencies. Coding is usually a minor problem. This can 
easily lead to the misperception that coding immediately produces the expected results, 
but this is not the case. To verify that the software meets the actual needs a considerable 
amount of testing is still mandatory. 

Testing is important. To achieve reliable results in coding, the rule of 
thumb is “code a little, test a lot.” Statistics can be discouraging; software development 


36 



lacks history and experience when compared to most hardware development, which uses 
mature processes and metrics. The software environment is immature. 

There is professional help available to provide competent assistance with 
the software development challenge. A major professional institution to assist is the 
Software Engineering Institute 45 . This organization is federally funded and can provide a 
lot of assistance in a great variety of developing and interoperability aspects of a major 
program. It should be used, which is the first recommendation. Seeking help from 
commercial programs, information websites, and federally funded institutions like the 
SEI can help accommodate the special needs for a program. A small variety of available 
software tools is listed in Table 6, but there are many more possibilities for assistance or 
obtaining a deeper insight into software development techniques. 

The second recommendation is to develop an IPT that allows the software 
developer to obtain all information necessary about the operational background of the 
new system. Contrary to the current JCIDS process, this information should be obtained 
by the combatant commanders, who are most familiar with user needs, and approved in 
the JCIDS process. This will ensure alignment with military doctrine as well as joint and 
net-centric perspectives. The detected capability gap will be more understood and 
articulated and redundant capabilities within the Services will no longer be produced. 

After the operational requirements are fully developed, there must be a 
constant exchange of information between the users and the software developers so that 
any identified requirements changes are discovered early in the process, before 
significant reengineering is required. 

b. Contractors, Software Development and Coding 

Software development requires an experienced and mature developer. 
Software developers should be comfortable with the prime contractor’s specific 
environment as well as the unique governmental needs and procedures. This can be 


45 Software Engineering Institute, http://www.sei.cmu.edu/ ast. Last accessed February 2008. 
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achieved by fostering strategic partnerships with the few contractors who have proven to 
be capable of producing results that meet the needs of the government. 

Another need is an IPT of users and software coders. This is required to 
maintain close control of the software development and provide software coders with 
necessary information about integration, common, current systems, and data presentation 
and exchange for facilitate effective software. Better results will be produced with less 
training for the new system, and therefore the numbers and size of errors, changes and 
late modifications to the user’s requirements will be reduced. 

Applying software metrics to this phase is also necessary. The contractor 
must be aware that his efforts to develop the software are appreciated, but also that 
inefficient procedures, excessive coding scrap, and poor results are not acceptable. This 
includes a metric for suitable an efficient coding. SLOCs are no longer an effective 
metric for software development. Numbers of functional points or other functionally 
oriented metrics are now used. An even better ratio of functional points represented by 
lines of codes used to achieve this goal should be requested. However, this ratio will be 
different depending on the maturity of the technique that must be represented, moved, 
provide data, or aid decisions. Nevertheless, this thought can be captured in a matrix, and 
better efficiency can be requested as part of a long term, strategic partnership. Incentives 
for efficient coding and thorough testing will produce faster results with higher quality. 

c. Software Security and Maintenance 

Software security and maintenance are valid concerns in every major 
weapon, information, and network system. A lot of emphasis is placed on establishing 
joint and net-centric warfare capabilities for warfighters. Large, complex networks, 
information systems, and data handling systems are especially vulnerable to espionage, 
hacking, spoofing, electronic countermeasures and exposure to the enemy. This applies 
particularly to ground and airborne systems. High value targets must be protected during 
wartime from any deterioration of capabilities to maintain information superiority and 
provide soldiers with the ability to make decisions, move first, and take advantage of 
surprise. This goal can be achieved by protecting crucial systems like satellites, networks, 
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and internet. These systems should be virtually unbreakable so they are always available 
when needed. Another method of achieving this is, once the network is safe, is to allow 
small software updates that are not downward compatible and protected. 

2. Operational and Functional Hardware Requirements 

a. Requirements Formulation 

Operational and functional requirement formulation must be the job of 
experienced users on the battlefield. Combatant Commanders, pilots, and platoon leaders 
are good examples. The operational aspect is best represented by the Combatant 
Commanders level; functional needs are closely related to users like pilots and leaders on 
the ground. 

The Combatant Commanders have a significant role in formulating 
requirements. They distinguish actual “needs” from “nice to have” demands. They are the 
most suitable individuals for this decision because they have the required level of 
operational insight and are near enough to the battlefield that they will not cut out 
essential attributes needed for success in the intended environment. However, Combatant 
Commanders do not have enough time to explicitly draft requirements for closing 
detected capability gaps. This problem could be solved if requirement specialists were 
easily accessible to them. The specialist would prepare preliminary performance 
specifications to be reviewed by the Combatant Commander and JCIDS process. 

b. Requirements/Implementation 

Requirements can be difficult to grasp, formulize or phrase. It is even 
more difficult to translate requirements into a language that leaves no room for ambiguity 
and gives contractors all the information necessary to understand the operational 
environment, complexity of work, and technological risks involved in the new system. 

The first recommendation is to use contracting specialists. Once a 
requirement is clear and approved, it should reviewed by a contract specialist. In an ideal 
case, there would be only a few questions about incentives and metrics needed to verify 
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and incentivize the performance. When the requirement is implemented into the contract, 
it is essential that the contractor has the same interpretation of the stated requirement as 
its developers. 

Apart from a detailed RFP and solicitation, a pre- award conference with 
possible contractors is the best alternative to communicate the government’s needs to the 
contractors. This could eliminate a lot of confusion, but requires detailed and professional 
preparation by the government. The contractor must demonstrate, in a pre-award 
conference, an understanding of the complexity, functional needs, and risks incorporated 
in the requirements. This means they must be given access to critical information before 
the conference in order to prepare. 

c. Performance Control 

There has been a huge amount of effort put into creating, wording, and 
implementing requirements into the contract; so much that the important step of linking 
them to the expected performance is diluted. Every requirement must be traceable to 
measurable performance metrics within the program. The current reward structure and 
incentives for the contractor must directly relate to these metrics to at least meet the 
objectives as stated in the contract. No fees or awards should be paid for objectives 
covering mandatory items of the contract. However, there must be enough incentives for 
delivering superior quality and performance on or ahead of schedule. A matrix of 
possible incentives is presented in Table 7. A current problem is the lack of incentives 
for a contractor to perform well and deliver quality and capabilities that exceed the 
government requirements. This is especially true for contracts that provide award fees on 
performance as stated in the contract. Every incentive given to a contractor should be 
based on verification and non arbitrary or ambiguous metrics and data. These incentives 
need to adapt to the needs of every single program, and suggest a more suitable incentive 
structure than ones in the past. 
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3. 


Acquisition Process and Management 


a. Funding 

Funding for the Department of Defense is based on four major factors: 
percentage of GDP, national needs in other departments, security environment, and 
requests from the Department of Defense. The first recommendation is to reverse the 
process of funding. Congress and the President of the United States must agree on a 
budget for the Department of Defense based on the criteria above. Once the amount is 
determined, the Secretary of Defense and the Joint Chiefs of Staff should prioritize 
national defense needs according to suggestions of the Services, based on the insights of 
their Combattant Commanders for new programs and their justification. Once this 
priority list is established, money should be divided among programs suggested by the 
Services in an order governed by this list. The President, Secretary of Defense, Joint 
Chiefs of Staff, and Service Chiefs would shift programs producing redundant 
capabilities to a specific Service, or they would be cancelled. 

The Accountability of the Services would be greater, if they were not 
competing for money directly from their sister Services, but instead for a fair partial share 
depending on national security, joint and network needs, and their unique capabilities. 
When the Services know how much money to expect, they can develop a plan for 
distributing it to programs that contribute the most to national needs. Everything that is 
not covered in this plan, like inadequate numbers of units within a program or smaller 
programs will appear in a gap list. This will identify the program, its least operational 
units/systems, how many of those units are desired, and how many are covered by 
funding. With these numbers, the Department of Defense could reach a compromise with 
Congress over additional funding and major contractors capable of providing the systems 
according to the budget. With this reversed flow, unit numbers and prices become much 
more reliable, and planning by contractors, the Services, and Department of Defense 
becomes easier. 

Another change should be implemented for time effective appropriation of 

money. Money that can not be spent during final three months should be partially 
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recoverable by the Services if a plan for the use of this money in the upcoming fiscal year 
for a purpose can be provided. An incentive to save money could definitely be reached at 
a share ratio Treasury/Service of 30/70 or above. 

These recommendations are not easily achieved. They ask for a 
considerable change of legal framework and individual attitude. Nevertheless, they seem 
to be worthwhile in the long run because they address several problem areas: jealousy 
among the Services, the influence of lobbyists and parochial working politicians, and 
dishonesty in projections of cost and schedule. 

b. Cutting Edge Technologies 

New materials, technological breakthroughs, and unprecedented 
technological capabilities are fascinating, but they come at a price. The research and 
development of new cutting edge technologies is costly, takes time, and bears the risk of 
total failure because of unexpected technical difficulties, material problems, and 
immature software. Regardless of this, requirement requests for these technologies are 
implemented in too many major programs. 

R&D efforts before the beginning of a program are insufficient, and there 
are too many immature components demanded. SBIRS high is a good example of the 
common mistake of rushing too early into a program without understanding the necessary 
background: complexity, software size, maturity level of components, and other 
challenges. Fascination with future possibilities impedes reasonable and intensive risk 
analysis. Overoptimistic assumptions lead to decisions lacking adequate standards, 
knowledge and wisdom. 

Development of those high risk areas must be separated from the program, 
and be treated like an upgrade that, although planned for, is not absolutely certain. It is 
better to delay a program an extra year to clarify maturity levels and build realistic 
confidence in the program than it is to rush into production without proper knowledge. 
The costs and schedule delays of programs where immature technology was accepted 
during CDR or production should have taught this lesson. 
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Money must be appropriated before for cutting edge technology is 
implemented into a program. The Department of Defense can assist in identifying 
promising technology to implement in future programs. The defense industry can provide 
information regarding the release dates of these technologies with a reasonable monetary 
effort; this will achieve the maturity needed for implementation into defense related 
programs. Industry and government must be mutually patient. While one must wait for 
technology to mature before introducing into defense programs, the other must wait to 
earn the money necessary to nurture this maturity. 

Technology must remain relevant enough to maintain an advantage over 
the enemy. Depending on the complexity of the system, this can mean gathering 
information, processing data, denying information and intelligence, moving first, or 
destroying targets while maintaining low vulnerability. When the lives of soldiers are 
involved, winning by only a margin is certainly not desirable. 

Scarce budget resources force the consideration of cutting back on these 
technologies. These technologies should not be renounced, but allowed the opportunity 
for maturity and better performance after upgrades. New open architectures provide this 
opportunity; A vast number of programs could prevent many problems, risk, and 
uncertainty. We must implement a better sanity check available to the acquisition 
community to decide whether cutting edge technology is mature enough to be 
implemented into a program or not. The maturity levels for components alone does not 
provide enough information as it evaluates partial aspects only but does not incorporate 
the integration and interface requirements of multiple components for modern systems- 
of-systems. The contractor can provide this information if they are not pressed to develop 
cutting edge technology and their program simultaneously, while under considerable 
schedule pressure. 


c. Legal Restrictions 

A factor that that has not been discussed yet is the impact of current legal 
restrictions on the acquisition process itself. The lists in Tables 3, 4 and 5 illustrate the 
amount of guidance, laws and regulations that apply to the acquisition process. For 
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Program Management the AKSS /DAU website list 529 mandatory documents that apply, 
for Software Acquisition Management alone 60 binding documents. It is assumed that 
these are intended to assist the acquisition workforce. Unfortunately, every major scandal 
and unsuccessful program was followed by an outcry from Congress for more regulations 
and guidance in the hope of eliminating the problem, but additional oversight adds to the 
management burden and may actually have an opposite result. 

The diminished contracting workforce cannot keep up with updates, new 
regulations, and changing guidelines. The intended purpose of assisting them is missed. 
The flood of regulations, laws and guidance hampers their ability to do their job. Many 
laws and regulations apply to an era of stable environments during the Cold War, when 
conventional planning for war and economies largely focused on continental needs. But 
the environment has changed. Global economies and interdependencies, national and 
social needs, regional conflicts and asymmetric warfare need different planning, 
guidelines and laws to guide the way. 

Global interdependencies drive the first recommendation. It is time to 
share responsibilities and privileges equally among allies. The demand for more 
adjustment, consultation, and combined effort is essential for addressing global 
challenges and threats in the near and long term future. National protection of defense 
contractors is a limiting factor to competition and a waste of resources. Like sharing 
capabilities within the Services, allies have to share their defense industry capabilities to 
allow competition, better pricing, and quality warfighting capabilities. 

The U.S. is no exception. The Buy American Act is a legacy that does not 
fit a global economies and defense efforts perspective. Sharing technologies among allies 
reduces procurement cost and produces innovation and higher levels of standardization. 
The security issue within this approach can be solved with a similar approach to the one 
discussed in the section about software security and maintenance. The impact on the 
defense industry would be more competition, and the danger for national workplaces 
could be minimized by arrangements where the systems are actually produced. Opening 
up national restrictions will allow a broader base of expertise and production. 

Cooperation in developing future systems will also stabilize.(See page 13) 
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d. Acquisition Flexibility 


Change in the acquisition environment calls for a variety of acquisition 
tools and processes. Some of the new procurement methods are evident in the area of 
contingency contracting. This type of procurement will be a part of fast responses to 
imminent needs in the future, especially during times of war. Lessons learned from recent 
years are applied, like the need for more continuous oversight and clearly expressed 
requirements, are useful for satisfying urgent needs. 

FAR part 13.5 46 contains an opportunity for easing the acquisition process 
for commercial item acquisition that is widely not applied. This particular section of the 
FAR is dedicated to easy acquisition procedures and save transaction costs to reduce the 
workload for the acquisition and contracting workforce. This section’s implications, as 
intended by Congress, are not commonly known or practiced. This section can save the 
Services approximately $9300 per transaction 47 and significantly reduce the workload. 
Last year alone, the Navy alone had 60,000 transactions that would have qualified under 
this section 48 . A simple clarification and reminder to all contracting specialists could 
reduce their workload and initiate instant savings. 

To use the latest improvements to diminish legal restrictions for 
procurement efforts and enhance acquisition flexibility like the Federal Acquisition 
Reform Act (FARA), Federal Acquisition Streamlining Act (FASA) and Service 
Acquisition Reform Act (SARA) are additional opportunities to booster commercial item 
acquisition and competition.. 

Global changes, different war environments and smaller armed services 
have created another challenge that requires focus and oversight. About 60% of the 
acquisition budget has already been spent on services, most of which are outsourced to 
civilian contractors. So much money is involved that promises made by the contractors 


4f) See also FAR, part 13 Simplified Acquisition Procedures, subpart 13.5 Test Program for Certain 
Commercial Items. 

47 According to comments in MN3304 contacting class, Yoder Cory. 

48 According to comments in MN3304 contracting class, Yoder Cory. 
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and random controls are not reliable. There is a need for a workforce large enough for 
constant oversight over performance, progress of the contract, and clear metrics for 
evaluation of their performance. Many complaints about lost money during contingency 
contracting and service contracts implicate the lack of availability and responsibility for 
oversight and follow up of the project or service. Evaluations based simply on the 
completion of a project are arbitrary, and do not achieve the best results possible based on 
the money used. 

Early service pioneers like postal services, catering agencies, warehouses, 
construction businesses and maintenance branches provide great models for the 
evaluation criteria that will allow a better determination of contractor performances. 
Combined with realistic requirement descriptions, these criteria will produce better 
results from outsourced services. 

K. SUMMARY 

The present difficulties in the acquisition process do not mean it is a broken 
system. Many aspects of the acquisition process have improved over time because of 
many adjustments made and lessons that have been incorporated into the best practices 
and regulations. There are deficiencies that must be addressed, but this is not an 
uncommon occurrence for complex organizations and processes. Sometimes the 
acquisition and contracting community is held responsible for inefficiencies, bad 
judgements and political decisions. They knew the decisions were wrong as far as the 
efficiency of the acquisition process was concerned, but could not prevent those 
decisions. As a consequence they suffered from those decisions made at a level out of 
their range of control, to be made and suffered from the consequences of those decisions 
out of their range of control. This should a frustration; there was no way to avoid this 
from happening, which is proof of the need for change and optimization in these 
processes. As economics, political and social environments, global challenges and war 
change, processes, regulations and laws need to adapt accordingly. It is impossible to 
keep up because the acquisition process cannot change over night, and requirements 
rapidly change as experienced in recent years. The acquisition process is adaptive. As the 
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best practices and learning are applied to current acquisition processes, they become 
more reliable. They will become even more reliable as more of the budget is spent on 
commercial services, which are easier to apply than cutting edge software, hardware, and 
program development. The identification of software and hardware-requirements, and 
their alignment with the different processes will always be crucial. This allows new 
systems within the right framework begin, as well as save money, allow quick 
procurement, and deliver the highest quality available to warfighters. 

L. FUTURE RESEARCH 

Future research is needed in the problem areas mentioned that but not explicitly 
covered. The most interesting fields at this point are: 

1. Behaviour of the DoD acquisition process regarding resistance to change 
in policy and change^ 9 . 

2. The willingness off political forces to align budgeting with the needs of 
the acquisition process. 

3. The influence of changes in the acquisition process moving towards a joint 
acquisition authority, rather than the sole responsibility of the services for 
“their” programs. 

4. The impact of an increasing amount of the defense budget for use on 
contractor services, and the government’s ability to require new systems 
and modernize equipment. 

5. How building strategic partnerships with contractors can reduce 
contracting regulations and save costs. 


49 See also Business Dynamics, Systems Thinking and Modeling for a Complex World, Sterman John 
D., p. 10, Chapter 1.1.2. 
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Exerpts from laws, regulations and guideline documents for the acquisition 
process 50 


Table 3. Federal Law 


2006 Quadrennial Defense Review (QDR) Strategic Communication (SC) Execution Roadmap 

Bid Protests at GAO: A Descriptive Guide Sixth Edition 

Changes to Process Standards Canceled Without Replacement on Existing Contracts Under the 
Single Process Initiative 

DoC Guide on Section 845/804 Other Transactions OTs for Prototype Projects 

DoD Evaluating the Price of Commercial Items in a Sole-Source Environment!nformation 
GuideVolume 2 

DOL Employment Law Guide 

DOL Federal Contract Compliance Manual 

E-Authentication Guidance for Federal Agencies 

EX. ORD 12995, Amendment to EX. ORD. NO. 12873; Federal Acguisition, Recycling, and Waste 
Prevention 

EX. ORD NO. 13148; Greening the Government through Leadership in Environmental Management 

EX. ORD. NO. 11514; Protection and Enhancement of Environmental Quality 

EX. ORD. NO. 12114; Environmental Effects Abroad of Major Federal Actions 

EX. ORD. NO. 12196; Occupational Safety and HeaIth Programs for Federal Employees 

EX. ORD. NO. 12591 Facilitating Access to Science and Technology 

EX. ORD. NO. 12770; Metric Usage in Federal Government Programs 

EX. ORD. NO. 12829 National Industrial Security Program 

EX. ORD. NO. 12856; Federal Compliance with Right-to-Know Laws and Pollution Prevention 
Reguirements 

EX. ORD. NO.12885; Amendment To Executive Order No.12829 

EX. ORD. NO. 12958 Classified National Security Information 

EX. ORD. NO. 12968 Access to Classified Information 

EX. ORD. NO. 13010 Critical Infrastructure Protection 

EX. ORD. NO. 13025; Amendment to EO 13010; Presidents Commission on Critical Infrastructure 
Protection 

EX. ORD. NO. 13026; Administration of Export Controls on Encryption Products 

EX. ORD. NO. 13041 Further Amendment to Executive Order 13010 

EX. ORD. NO. 13064 Further Amendment to Executive Order 13010; Critical Infrastructure 
Protection 

EX. ORDER NO. 13392; Improving Agency Disclosure of Information 

Ex.Ord. 13423 Strenghening Federal Environmental, Energy, and Transporation Management 

Executive Order: Providing Opportunities for Service-Disabled Veteran Businesses to Increase Their 
Federal Contracting and Subcontracting 

Executive Order: Strengthening Federal Environmental, Energy, and Transportation Management 

Export Administration Regulations Database 

Field Manual (FM) 3-100.21 (formerly FM 200-21), Contractors on the Battlefield 

GSA Acguisition Letter V 04-05: Purchases on Behalf of Other Agencies 

Industrial Security Letter ISL 2006-02 

Instructions for Modular Open Systems Approach (MOSA) Implementation; USD (AT&L) Memo 

MARCOR Project Officers Certification and Accreditation Flandbook E. Certification Analysis 
Reguirements 

MARCOR Systems Cost Analysis Flandbook E. Life Cycle Cost Estimate (LCCE) Example 

MARCOR Systems Cost Analysis Flandbook II. Users Manual, Summary Version Life Cycle Cost 
Model (SVLCCM),Version 3.2 

NAVSUP P-505 Preparing Hazardous Materials for Military Air Shipments 


50 See also https://akss.dau.mil/Lists/Policy/Documents/ for more information. 
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Federal Law (continued) 


OFPP Memorandum, "Directly Interested Party" Clarification Memo 

OFPP Memorandum, 2005 Alternative Dispute Resolution Awards in Acquisition 

OFPP Memorandum, Agency Requirement for a plan to Transition to the Federal Procurement Data 
System (FPDS) 

OFPP Memorandum, Avoiding Duplication of Agency Activities with the Presidential E-Government 
and Lines of Business Initiatives 

OFPP Memorandum, Buy American Reporting Requirement 

OFPP Memorandum, Buying Accessible Electronic and Information Technology and Complying with 
Section 508 of the Rehabilitation Act 

OFPP Memorandum, Contractor Responsibility Determinations and 1 ndefinite-Delivery Contracts 

OFPP Memorandum, Developing the Acquisition Management Skills of the Architectural and 
Engineering Workforce 

OFPP Memorandum, Development of "Green" Plans for Competetive Sourcing 

OFPP Memorandum, Establishment of Interagency Acquisition Workinq Group 

OFPP Memorandum, Federal Acquisition Institute Board of Directors Charter 

OFPP Memorandum, Implementing Management Controls to Support Increased Micro-purchase 
Threshold for Hurricane Katrina Rescue and Relief Operations 

OFPP Memorandum, Implementing Strateqic Sourcinq 

OFPP Memorandum, Limitation on Use of Special Micro-purchase Threshold Authority for Hurricane 
Katrina Rescue and Relief Operations 

OFPP Memorandum, M-02-05, Use of Government Purchase and Travel Cards 

OFPP Memorandum, M-04-12, Performance Periods in Public-Private Competitions 

OFPP Memorandum, M-05-01, Report to Conqress on FY 2004 Competitive Soourcinq Efforts 

OFPP Memorandum, M-06-01, Report to Conqress on FY 2005 Competitive Sourcinq Efforts 

OFPP Memorandum, Publication of Brand Name J ustifications 

OFPP Memorandum, Recession of Monthly Reporting on Electronic Commerce Statistics to the 
General Services Administration 

OFPP Memorandum, Report on Competitive Sourcing Results, Fiscal Year 2004 

OFPP Memorandum, Request Contracting Information on Contractors Operatinq in Iraq 

OFPP Memorandum, Revised FAR Process 

OFPP Memorandum, The Federal Acquisition Certification in Contracting Program 

OFPP Memorandum, The Presidents Welfare to Work Program 

OFPP Memorandum, Update on the Electronic Subcontracting Reportinq System 

OFPP Memorandum, Utilization of Commercially Available Online Procurement Services 

OFPP Policy Letter 05-01, Developing and Manaqinq the Acquisition Workforce 

OFPP Policy Letter 80-1; Section 211 of Public Law 95-507, Subcontracting: Agency Coordination 
with the Small Business Administration Resident Procurement Center Representatives 

OFPP Policy Letter 80-2, Supp 1; Requlatory Guidance on Section 211; of Public Law 95-507 

OFPP Policy Letter 80-4; Womens Business Enterprise Program 

OFPP Policy Letter 91-3; Reporting Nonconforming Products 

OFPP Policy Letter 92-1; Inherently Governmental Functions 

OFPP Policy Letter 92-4; Procurement of Environmentally-Sound and Energy-Efficient Products and 
Services 

OFPP Policy Letter 93-1 (Reissued); Management Oversight of Service Contracting 

OFPP Policy Letter 99-1, Small Business Procurement Goals 

OMB Circular A-l; Bureau of the Budgets System of Circulars and Bulletins to Executive 
Departments and Establishments; Revised 

OMB Circular A-102; Grants and Cooperative Agreements With State and Local Governments; 
Revised 

OMB Circular A-109; Major Systems Acquisitions 

OMB Circular A-11; Preparinq and Submitting Budget Estimates 

OMB Circular A-110; Uniform Administrative Requirements for Grants and Agreements With 
Institutions of Higher Education, Hospitals,...; 

OMB Circular A-122; Cost Principles for Nonprofit Organizations 
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Federal Law (continued) 


OMB Circular A-123; Management Accountability and Control 

OMB Circular A-126; Improving the Management and Use of Government Aircraft; (Revised) 

OMB Circular A-127; Financial Management Systems; Revised -- Transmittal Letter 2 

OMB Circular A-129; Policies for Federal Credit Programs and Non-Tax Receivables 

OMB Circular A-130 Management of Federal Information Resources 

OMB Circular A-131; Value Engineering 

OMB Circular A-133; Audits of States, Local Governments, and Non-Profit Institutions 

OMB Circular A-134; Financial Accounting Principles and Standards 

OMB Circular A-135; Management of Federal Advisory Committees 

OMB Circular A-136, Financial Reporting Reguirements 

OMB Circular A-16; Coordination of Surveying, Mapping, and Related Spatial Data Activities; 
Revised 

OMB Circular A-19; Legislative Coordination and Clearance; Revised 

OMB Circular A-21; Cost Principles for Educational Institutions 

OMB Circular A-25; User Charges; Revised -- (Transmittal Memorandum No.l) 

OMB Circular A-34; Instruction on Budget (Superceded by OMB Circular A-11, Part 4) Execution 

OMB Circular A-45; Rental and Construction of Government Quarters; (Revised) 

OMB Circular A-50; Audit Followup; Revised 

OMB Circular A-76 

OMB Circular A-76 (Revised) Transmittal Memorandum No.22; Performance of Commercial 
Activities 

OMB Circular A-76; Revised Supplemental Plandbook; Performance of Commercial Activities 

OMB Circular A-76; Transmittal Memorandum No.20; Implementation of the Federal Activities 
Inventory Reform Act of 1998 (Public Law 105-270) (FAIR Act) 

OMB Circular A-87; Cost Principles for State, Local and Indian Tribal Governments; Revised 

OMB Circular A-89; Federal Domestic Assistance Program Information; Revised 

OMB Circular A-94; Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs; 
Revised 

OMB Circular A-97; Rules and Regulations Permitting Federal Agencies to Provide Specialized or 
Technical Services to State and Local Units of Government Under Title 111 of the 1 ntergovernmental 

OMB M-3-14, Reducing Cost and Improving Quality in Federal Purchases of Software 

OMB Memorandum 04-07, Report to Congress on FY 2003 Competitive Sourcing Efforts 

OMB Memorandum M-00-07 Incorporating and Funding Security in Information Systems 
Investments 

OMB Memorandum; Compensation Benchmark Amount Pursuant to Section 808 of Public Law 105- 
85 

OMB Privacy Policies and Data Collection on DoD Public Web Sites 

Presidential Policy on Offsets in Military Export 

Protests, Claims, and Alternative Dispute Resolution (ADR) as Factors in Past Performance and 
Source Selection Decisions 

SECNAVINST 5510.36A DEPARTMENT OF THE NAVY (DON) INFORMATION SECURITY PROGRAM 
(ISP) INSTRUCTION 

Technology Protection -- ProgramManagement Education 

United States Code 
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Table 4. Statutory Laws 


2006 Quadrennial Defense Review (QDR) Strategic Communication (SC) Execution Roadmap 

Clean Air Act, 42 U.S.C. s/s 7401 (1970) 

Clean Water Act 

Clinqer-Cohen Act of 1996 

Comprehensive Environmental Response, Compensation, and Liability Act (Superfund), 42 U.S.C. 
s/s 9601, (1980) 

DoD 4500.9-R Defense Transportation Regulation, Pt II, Cargo Movement, Attachment V7, FMS 
Shipments 

Emergency Planning & Community Right to Know Act, 42 U.S.C. 11001 

Endangered Species Act, 7 U.S.C. 136; 16 U.S.C. 460, (1973) 

Environmental Impact Analysis Process (EIAP), 32 CFR 989 

Federal Acquisition Reform Act (FARA) of 1996 

Federal Acquisition Streamlining Act (FASA) 

Federal Information Security Management Act 

Freedom of Information Act, 5 U.S.C. s/s 552 (1996) 

Marine Protection, Research, and Sanctuaries Act, 33 USC 1401, (1972) 

Military Munitions Rule, 42 U.S.C. s/s 300f, (1974) 

National Environmental Policy Act, 42 USC, Sections 4321 thru 4347 

Noise Control Act, 42 USC 4901, (1996) 

Occupational Safety and Health Act, 29 U.S.C. 651, (1970) 

Oil Pollution Act, 33 U.S.C. 2702 to 2761 

P. L. 107-347 U. S. Code 44 Ch 36, E-Govemment Act of 2002 

P. L. 108-375 SEC. 811. RAPID ACQUISITION AUTHORITY TO RESPOND TO COMBAT EMERGENCIES. 

P.L. 100-235 - (H.R. 145); Computer Security Act of 1987 

P.L. 100-533 - (H.R. 5050); Womens Business Ownership Act of 1988 

P.L. 104-106; National Defense Authorization Act for Fiscal Year 1996 

P.L. 104-13; Paperwork Reduction Act of 1995 

P.L. 104-164 - (H.R. 3121); Defense and Security Assistance Improvements 

P.L. 104-320; The Administrative Dispute Resolution Act of 1996 

P.L. 106-79; Department of Defense Appropriations Act, 2000 (Excepts) 

P.L. 107-314; Bob Stump National Defense Authorization Act for Fiscal Year 2003 

P.L. 97-255 - (H.R. 1526); Federal Managers Financial Integrity Act of 1982 

Pollution Prevention Act 1990, 42 U.S.C. 13101 and 13102, (1990) 

Privacy Act of 1974 5 U.S.C. A§ 552a 

Resource Conservation & Recovery Act (RCRA), 42 U.S.C. s/s 6901, (1976) 

Section 8088, Public Law 107-248 Registering Financial Management Information Technology Systems with DoD 
Chief Information Officer 

Section 8102 DoD Appropriations Act.doc, P.L. 106-259, Section 8102 (DoD Appropriations Act, 2001) 

Services Acquisition Reform Act (SARA) of 2003. 

Title 10, Part II, Chapter 87, Section 1702USD/AT&L Authorities and Reponsibilities 

Title 10, Part II, Chapter 87, Section 1703Director of Acquisition Education, Training, and Career Development 

Title 10, Part II, Chapter 87, Section 1704:Service acquisition executives: authorities and responsibilities 

Title 10, Part II, Chapter 87, Section 1721 designation of Acquisition Positions 

Title 10, Part II, Chapter 87, Section 1723:General education, training, and experience requirements 

Title 10, Part II, Chapter 87, Section 1724:Contracting positions qualification requirements 

Title 10, Part II, Chapter 87, Section 1725:Office of Personnel Management Approval 

Title 10, Part II, Chapter 87, Section 1731 :Acquisition Corps in General. 

Title 10, Part II, Chapter 87, Section 1732:Selection Criteria and Procedures 

Title 10, Part II, Chapter 87, Section 1733:Critical Acquisition Positions 

Title 10, Part II, Chapter 87, Section 1734:Career Development 

Title 10, Part II, Chapter 87, Section 1735:Education, training, and experience requirements for critical acquisition 
positions 

Title 10, Part II, Chapter 87, Section 1737:Definitions and General Provisions 

Title 10, Part II, Chapter 87, Section 1741 Policies and programs: establishment and implementation 

Title 10, Part II, Chapter 87, Section 1742:lntern Program 
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Statutory Laws (continued) 


Title 10, Part II, Chapter 87, Section 1745:Additional education and training programs available to acquisition 
personnel 

Title 10, Part II, Chapter 87, Section 1746:Defense acquisition university structure 

Title 10, Part II, Chapter 87, Section 1761 :Management Information Systems 

Title 10, Part II, Chpater 87, Section 1701, Management Policies 

Title 10, Part II, Chpater 87, Section 1764, Repealed 

Title 10, Part IV, Chapter 146, Section 2460: Definition of depot-level maintenance and repair 

Title 10, Section 139, U.S.C., Director of Test and Evaluation 

Title 10, Section 2302, U.S. Code, Definitions 

Title 10, Section 2302d, U.S.Code - Major system: definitional threshold amounts 

Title 10, Section 2341, U.S.C., Authority to acquire logistic support, supplies, and services for elements of the 
armed forces deployed outside the United States 

Title 10, Section 2342, U.S.C., Cross-servicing agreements 

Title 10, Section 2350a, U.S.C.,Cooperative Research and Development Projects: Allied Countries 

Title 10, Section 2364, U.S.C., Coordination and Communication of Defense Research Activities 

Title 10, Section 2366, U.S.C., Major Systems and Munitions Programs: Survivability and Lethality Testing 
Required Before Full-scale Production 

Title 10, Section 2377, U.S.C., Preference for Acquisition of Commercial Items 

Title 10, Section 2399, U.S.C., Operational Test and Evaluation of Defense Acquisition Programs 

Title 10, Section 2400, U.S.C., Low-rate Initial Production of New Systems 

Title 10, Section 2430, U.S.C., Major Defense Acquisition Program Defined 

Title 10, Section 2432, U.S.C., Selected Acquisition Reports 

Title 10, Section 2433, U.S.C., Unit Cost Reports 

Title 10, Section 2434, U.S.C., Independent Cost Estimates; Operational Manpower Requirements 

Title 10, Section 2435, U.S.C., Baseline Description 

Title 10, Section 2440, U.S.C., Technology and Industrial Base Plans 

Title 10, Section 2464, U.S.C., Core Logistics Functions 

Title 10, Section 2466, U.S.C., Limitations on the Performance of Depot-Level Maintenance of Material 

Title 10, Section 2469, U.S.C., Contracts to Perform Workloads Previously Performed by Depot-Level Activities of 
the Department of Defense; Requirement of Competition 

Title 10, Section 2531, U.S.C., Defense memoranda of understanding and related agreements 

Title 10, Section II, Chapter 87, Section 1722:Career Development 

Title 10, U.S. Military Forces Military Law 

Title 10. Section II, Chapter 87, Section 1705:Directors of Acquisition Career Management in the military 
departments 

Title 15, Section 644, U.S. Code, Awards or Contracts 

Title 22, Section 2751, U.S.C., Need for international defense cooperation and military export controls; 
Presidential waiver; report to Congress; arms sales policy 

Title 44, Chapter 31, Records Management by Federal Agencies 

Title 47, Section 305, U.S.C., Government-Owned Stations 

Title 47, Section 901, U.S.C., Definitions; findings; policy (National Telecommunications & Information 
Administration 

Title 47, Section 902, Establishment; assignment functions (National Telecon & Information Administrtion) 

Title 47, Section 903, U.S.C., Spectrum management activities, (National Telecommunications & Information 
Administration) 

Title 47, Section 904, U.S.C., General administrative provisions 

Title 5, Section 306, U.S.C., Strategic Plans (part of the Government Performance and Results Act) 

U.S. Code 10, Chapter 131, Sec. 2220. - Performance based management: acquisition programs 
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Table 5. Federal Acquisition Regulation (Supplements) 


AFARS Part 5123, Environment, Conservation, Occupational Safety, and Drug-Free Workplace 

AFARS Part 5125, Foreign Acquisition 

AFFARS - Part 5325; Foreign Acquisition; AFAC 96-2 

AFMCFARS - Part 5325; Foreign Acquisition 

Air Combat Command FAR Supplement (ACCFARS) 

Air Education & Training Command FAR Supplement (AETCFARS) 

Air Force FAR Supplement (AFFARS) 

Air Force Materiel Command FAR Supplement (AFMCFARS) 

Air Force Reserve Command FAR Supplement (AFRC) 

Air Force Space Command FAR Supplement (AFSPCFARS) 

Air Mobility Command FAR Supplement (AMCFARS) 

Army Federal Acquisition Regulation Manual No. 2 (Contingency Contracting) 

Army Federal Acquisition Regulation Supplement (AFARS) 

Defense Federal Acquisition Regulation Supplement, Procedures, Guidance & Information (DFARS PGI) 

Department of Energy FAR Supplement (DEARS) 

Environmental Protection Agency Acquisition Regulation (EPAAR) 

FORSCOM FAR Supplements 

General Services Administration Acquisition Manual (GSAM) 

MARCOR Systems Cost Analysis Flandbook D.15. Material Consumption 

National Aeronautics and Space Administration FAR Supplement (NFS) 

National Guard FAR Supplement (NGFARS) 

Navy Marine Corps Acquisition Regulation Supplement(NMCARS) 

NMCARS Part 5225; Foreign Acquisition; Through Change 97-15 

Performance-Based Service Acquisition (PBSA) 

U.S. Army Corps of Engineers FAR Supplement (EFARS) 

U.S. Special Operations Command FAR Supplement (SOFARS) 
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Table 6. Helpful tools for developing software 51 






Aircraft Sustainability Model 
(ASM 7) 

Air Force 

AFMC 

AF spec to Action 
Officers 

Pre-Award Information 

Exchange System (PIXS 5.0) 

Air Force 

ASC/SYG 


SEER-Hardware Estimation 
Model (SEER-H) 

Air Force 

ASC/FMCE 


Formal Risk Analysis (FRISK 
4.00) 

Air Force 

SMC/FMC 

COTS- 

Aerospace Corp 

Cost Management 

PRICE TruePlanning 

Air Force 

ASC/FMCE 

Price Estimating - 
Contracting 

Process Analysis and Project 
Integrated Environment 

Air Force 

SMC/Det 11 

Project Management 

Data Item Descriptions Advisor 

Air Force 

AFMC 

Requirements 

Cost/Risk Identification & 
Management System (CRIMS 

Air Force SAF/AQXR Send 
Email 

Air Force 

SAF/AQXR 

Risk Assessment 

Security Information 

Management System (SIMS) 

Air Force 

AFML/COTS- 
SIMS Software 

Security Management 

Applied Computational Fluid 
Dynamics (ACFD) 

Air Force 

Eglin Air Force 
Base 

Modeling Sim 

AFTOC Management 

Information System 

Air Force 

SAF/AFCAA 

Total Ownership Cost 

Risk AoA (Predictive Risk 
Analysis for the AoA process) 

Air Force 

AFMC 

Cost Analysis; Project 
Management; Risk 
Assessment 


51 See also AT&L Knowledge Sharing System https://akss.dau.mil/default.aspx. 
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Table 7. Incentives to boost contractor performance 


Incentive 

Based on* 

Share of cost savings at a certain rate 

Cost savings for the government 

Additional profit / increased production 
numbers / strategic partnership with long 
term contracts 

Enhanced mission capabilities in the stated 
operational environment due to exceeded 
government requirements 

Additional profit or increased production 
numbers 

Design for easy ubgradeability/ 
interoperability 

Additional profit 

Better quality and increased MTBF, AoA 

Additional profit 

Better maintenance support over an extended 
life-cycle 

Additional profit 

Low amount of software maintenance 
needed 

Additional profit 

Low amount of maintenance needed 

Additional profit 

Low amount of training needed 


*the different sections have to be supported by clear metrics to justify being eligible for 
an increased amount of profit or other benefit. 
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